REMARKS 

In the Office Action dated March 23 , 2005 , the Examiner indicates that 
claims 1 though 10, 16 and 17 stand rejected under 35 U.S.C. 102(e) as being anticipated 
by U.S. Patent No. 6,289,462 to McNabb, et al. ("McNabb"). The Examiner further 
rejects claim 1 as being indefinite under 35 U.S.C. 1 12, \2 for failing to particularly point 
out and distinctly claimed the subject matter which the Applicants regard as the 
invention. More specifically, the Examiner asserts that claim 1 is indefinite because it is 
unclear in the first element of the claim whether a first message and a second message is 
received or whether a first message is received which contains a set of actions and a 
second message. Applicant wishes to thank the Examiner for his observation and hereby 
amends claim 1 to clarify the first element. The amendment to the claim is supported by 
the application as originally filed and does not introduce new matter. Accordingly, entry 
of the amendment to claim 1 is respectfully submitted. 

McNabb discusses a trusted compartmentalized computer operating 
system for controlling access to the execution of processes by applying file level 
extended sensitivity label attributes. Abstract. The attributes are utilized to restrict 
execution of processes that are requested by comparing the extended attributes, in 
addition to using standard file permission authorization. Abstract. According to 
McNabb, a method for processing requests includes the "steps of: receiving an incoming 
request for a data object; assigning a sensitivity label to an incoming request for a data 
object; reading extended attributes at a first storage destination associated with the data 
object; redirecting the incoming request to a second storage destination for the data object 
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based on the combination of the sensitivity label and the extended attributes; [and] 
executing an action associated with the redirected request." Col. 5, Ins. 20-30. 

McNabb also discusses a method for executing a commercial software 
product on a trusted server in a non-configuration mode that includes "the steps of: 
receiving a request related to the commercial software product at the trusted server 
comprising a request name, and address indicia; assigning a sensitivity level from the 
address indicia for the request related with the commercial software product; determining 
from the request a first location for a process to be executed for the commercial software 
product; retrieving the applied attributes for the process of the commercial software 
product stored at the first location; comparing the applied attributes to the assigned 
sensitivity level for the request, [and] executing the process requested where the process 
retrieved is correlated to the applied sensitivity level." Col. 5, Ins. 47-61. 

By contrast to McNabb, independent claim 1 of the present application is 
direct to a method for authorizing execution of requested actions transmitted between 
clients and servers of a data processing system. The method of claim 1 comprises the 
steps of receiving a first message including a set of actions, and a second message 
including user-requested actions and inputs; simulating execution of the set of actions and 
building a list of allowable actions and user-definable inputs to the allowable actions; 
comparing the list of allowable actions and user-definable inputs to the user-requested 
actions and inputs; and where the list of allowable actions and user-definable inputs 
includes the user-requested actions and inputs, authorizing execution of the user- 
requested actions. 
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McNabb fails to teach or suggest the element of receiving a first message 
including a set of actions, and a second message including user-requested actions and 
inputs. The Examiner correctly points out that McNabb discusses providing "a user ID 
and authentication response (such as a password, a biometric device, a smart card, or an 
access token)" and that once authenticated, "subsequent web requests can be identified . . 
. as part of an authenticated session". Col. 15, Ins. 54-61. The authentication process of 
McNabb, however, is silent regarding receiving a first message including a set of actions, 
and a second message including user-requested actions and inputs. Although the 
Examiner asserts that providing a user ID and authentication request is a first message 
including a set of actions, McNabb only discusses providing a user ID and authentication 
response and makes no mention of including a set of actions. Col. 15, Ins. 54-58. 
Indeed, the passages upon which the Examiner relies make no mention of receiving a set 
of actions and is limited to a user ID and authentication response. Similarly, although the 
Examiner asserts that identifying subsequent requests as part of a session satisfies the 
element of receiving a second message including user-requested actions and inputs, 
McNabb is silent regarding the receipt of a second message that includes user-requested 
actions and inputs. Col. 15, Ins. 58-61. 

The Examiner also correctly indicates that McNabb discusses the 
integration of simulation software into a trusted compartmentalized computer operating 
system. Col. 21, Ins. 51-65. The Examiner is incorrect, however, regarding the use of 
the simulation software, which is for performance tuning purposes and not building a list 
of allowable actions and user-definable inputs to the allowable actions. Col. 21, Ins. 50- 
54. According to McNabb, the simulation software "may assist in providing a 
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representation of a user } s process interactions and requests where the output may be 
directed to administrators using an email process for any processes the deviates from the 
predefined paths defined in the original system." (emphasis added) Col. 21, Ins. 55-60. 
Although the simulation software provides a representation of a user's process 
interactions and requests, McNabb, however, is silent regarding simulating execution of 
the set of actions (received in a first message) and building a list of allowable actions and 
user-definable inputs to the allowable actions. That is, contrary to the Examiner's 
assertion, McNabb only provides a representation of a user's process interactions and 
requests, as opposed to simulating execution of a set of actions and building a list of 
allowable actions and user-definable inputs to the allowable actions, as claimed. 

The Examiner is further correct that McNabb discusses modifying the 
graphical representation of the simulation software into a tabular or linked list form that 
may then be used by the UDE and the security gate to control process activities. Col. 21, 
Ins. 62-65. Contrary to the Examiner's conclusion, however, there is no teaching or 
suggestion by McNabb of simulating execution of the set of actions received in a first 
message as claimed. The simulation software of McNabb does not build a list of 
allowable actions and user-definable inputs to the allowable inputs as claimed. On the 
basis of the foregoing, McNabb fails to teach or suggest the elements of independent 
claim 1, and Applicant's respectfully request withdrawal of the rejection of claim 1 and 
allowance of the same. 

Independent claim 16 is directed towards a method performed by a 
gateway for authorizing requested actions transmitted from a client to a server of a 
client/server data processing system. According to claim 16, the method comprises, 
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among other elements, receiving, from the server, a document including a set of actions 
and simulating execution of the set of actions and building a list of allowable actions and 
user-definable inputs to the allowable actions. As discussed above, the simulation 
software that McNabb discusses provides a representation of a user's process interactions 
and requests, as opposed to simulating execution a set of actions and building a list of 
allowable actions and user-definable inputs to the allowable actions as claimed. 
Furthermore, McNabb is silent regarding comparing the list of allowable actions and 
user-definable imputer to the user-requested actions and inputs. McNabb fails to teach or 
suggest at least the claimed steps of simulating execution of the set of actions and 
comparing the list of allowable actions. Accordingly, McNabb fails to teach or suggest 
the elements of independent claim 16, and Applicant's respectfully request withdrawal of 
the rejection of claim 16 and allowance of the same. 

The dependent claims of the present application contain additional 
features that further substantially distinguish the invention of the present application over 
the prior art of record. Given the applicants' position on the patentability of the 
independent claims, however, it is not deemed necessary at this point to delineate such 
distinctions. 
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For at least all of the above reasons, Applicants respectfully request that the 
Examiner withdraw all rejections and objections, and allowance of all the pending claims is 
respectfully solicited. To expedite prosecution of this application to allowance, the 
examiner is invited to call the applicants' undersigned representative to discuss any issues 
relating to this application. 
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